Любой, кто изучал HTML и разрабатывал для Web, слышал подобный вопрос: “Зачем учить все эти теги и их атрибуты, когда можно просто воспользоваться WYSIWYG-редактором?”
Вопрос резонный, поэтому некоторым web-разработчикам, предпочитающим набирать HTML-код руками, мы задали вопрос, почему они это делают. Вот какие они выдвинули аргументы:
Контроль над кодом
Текстовый редактор HTML-кода в точности показывает вам какие теги и какие атрибуты вы используете в коде страницы. Таким образом вы получаете больший контроль над тем, как выводится страница. Например в WYSIWYG-редакторе вы нажали несколько раз Enter, чтобы начать новый абзац. Что именно вставил в код редактор? Два тега < ВR> или один тег < Р>? Или, скажем, вы выделяете содержимое ячейки в таблице и нажимаете в редакторе кнопку, которая центрирует это содержимое. Редактор за вас пишет в код что-то из этого:
td align=”center” ; p align=”center” ; div align=”center”
Но что именно? Для этого вам необходимо заглянуть в исходный текст. Для вас это играет большую роль? Ну, если страница выглядит так, как вы хотите, то, наверное, - нет. Но есть причины, из-за которых для множества разработчиков код, написанный в странице, важен:
Ни один броузер не поддерживает абсолютно все теги и их атрибуты, и иногда приходится проверять, что редактор вставил тот тег и атрибут, который будет понятен всем броузерам.
Для достижения желаемой компоновки страницы часто требуется тонкая игра со значениями атрибутов различных тегов, как например вертикальные и горизонтальные отступы вокруг изображений.
Когда проводится обширное изменение или обновление дизайна, наиболее эффективный способ - воспользоваться расширенной функцией замены, вместо того, чтобы вручную редактировать каждую страницу в отдельности; но расширенная замена будет работать только в том случае, если код всех ваших страниц одинаков, а для этого, вам надо точно знать, какой именно код написан в каждой странице.
Более эффективный код
Страницы, созданные в режиме WYSIWYG, часто оказываются значительно более тяжелыми, чем такие же страницы, созданные вручную. Причин несколько. Во-первых, когда вы выделяете текст и перемещаете или удаляете его, редактор должен догадаться, что же вы от него хотите: выделить только текст или текст вместе с окружающими его тегами. Если он угадает неверно, скорей всего он создаст те же самые теги в новом месте, а в старом оставит пустые старые теги. Вы этого не заметите, так как с вашей точки зрения страница будет выглядеть правильно.
Во-вторых, если вы решите отказаться от примененного форматирования текста (например, увеличенный размер шрифта), редактор, вместо того, чтобы удалить форматирующие теги, может применить противоположный эффект (уменьшающий размер шрифта) поверх уже существующего. Таким образом вы получите два тега, которые противодействуют друг другу и в результате ничего не делают.
В-третьих, самое неприятное. Если вы пользуетесь каким-либо WYSIWYG-редактором для конвертации Word-документа в HTML, вы получаете код, в котором для точной передачи горизонтальных и вертикальных отступов используется бесконечное число списков и пустых ячеек многочисленных вложенных таблиц.
WYSIWYG-редакторы делают больший упор на физическое, а не на структурное форматирование документа
Беглый взгляд на панель инструментов большинства WYSIWYG-программ подтверждает этот тезис. Наиболее ярко на панели выделяются кнопки меняющие свойства текста - то есть те, которые нам наиболее знакомы по текстовым редакторам. (что, впрочем, для текстовых редакторов тоже не самое лучшее, так как вместо этих кнопок пользователям лучше стоило бы пользоваться стилями, но это уже совсем другая тема…).
Функции, позволяющие применить к тексту тег заголовка, создать титул таблицы, или отступ, скрыты от глаз. В некоторых случаях приходится глубоко зарываться в меню, пока не найдешь способ вставить в од нужный логический тег. Это оправдано с точки зрения WYSIWYG-редакторов, которые пытаются “защитить” пользователя от непонятностей HTML, но не с точки зрения самого HTML. Использование HTML-тегов для управления видом документа противоречит самому духу HTML, который изначально создавался как язык описания структуры документа, наподобие SGML. В спецификации HTML 4.0 World Wide Web Consortium четко выразил эту мысль: HTML должен использоваться для описания структуры информации, а для управления ее представлением должны использоваться таблицы стилей. Теги физического форматирования, такие как FONT, U, STRIKE и CENTER отныне официально отменены (см. http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.3.5).
И это не прихоть борцов за чистоту HTML, старающихся усложнить жизнь простым пользователям: сведение к минимуму или к нулю элементов физического форматирования позволяет создавать более простые HTML-документы с меньшим количеством синтаксических ошибок, документы, которые проще поддерживать. (в таких языках как SGML и XML структура и физическое форматирование строго разделены).
Гибкость
Помимо вопроса структурного форматирования в противоположность физическому, WYSIWYG-редакторы ограничивают набор тегов, которыми вам разрешается пользоваться. Иногда не существует иного способа вставить тот или иной тег, кроме как переключившись в исходный HTML-код страницы. Текстовые HTML-редакторы же позволяют запросто вставлять любой тег и его атрибут по определению.
WYSIWY(NT)G (что на экране, то и в результате… у вас, но не у всех остальных) (what you see is you [not they] get)
Разработчикам сайтов не надо два раза напоминать о прописной истине: каждый броузер (и даже версия броузера) показывает HTML-код по-разному. В некоторых случаях можно обойтись базовым HTML, который будет одинаково интерпретирован всеми броузерами, но в большинстве случаев приходится искать обходные пути, чтобы решить эту проблему. Конечно текстовые HTML-редакторы не гарантируют вам создания универсального кода, но в целом в них проще вставить нужный тег или задать его атрибут, чем в WYSIWYG-редакторе. И что более важно, так как вы видите тег и сами выбираете его, невелик шанс, что вы выберите не тот тег и его атрибут, который приведет к ошибкам в других броузерах.
Скорость
Принцип WYSIWYG выливается в огромные затраты ресурсов. Всякий раз, когда вы нажимаете клавишу, программа должна перечитать получающийся код и соответственно обновить отображение страницы. Время, требуемое на перечитывание и обновление страницы зависит от эффективности самой программы, размеров и сложности страницы, количества используемой на ней графики и надежности системы. Возможно вы и не заметите задержек при работе в определенной программе на определенной системе, но хорошо написанный текстовый редактор будет всегда работать быстрее, чем WYSIWYG-редактор.
При всех перечисленных аргументах, есть ли причины, по которым я могу оставить WYSIWYG-редактор на своей машине? Конечно. Здесь нет дилеммы “или-или”. Создание HTML-страниц - это наполовину написание кода, наполовину ввод данных. По нашему мнению такой прекрасный текстовый HTML-редактор как HomeSite прекрасно подходит для написания кода, а WYSIWYG-редактор вполне пригодится, когда надо будет наполнять страницу содержимым, или менять таблицу. Но если бы все-таки пришлось выбирать - “либо то, либо это” - мы бы выбрали… ну в общем вы поняли…